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REMARKS 

The Examiner rejected claims 1, 3-6, 1 1-15, 17-19, 25, and 27-29 pursuant to 35 U.S.C. 
§103(a) as unpatentable over Smith, et al. (US 6,241,675) in view of Park (US 6,192,164). 
Claim 2 was rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Smith, et al. in view of 
Park, and further in view of Zar (A Scan Conversion Engine...). Claims 7 and 20 were rejected 
pursuant to 35 U.S.C. § 103(a) as unpatentable over Smith, et al. in view of Park and Drebin, et 
al. (US 4,835,712). Claims 9 and 22 were rejected pursuant to 35 U.S.C. §103(a) as 
unpatentable over Smith, et al. in view of Park and Swerdloff (US 5,483,567). Claims 24 and 
26 were rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Smith, et al. in view of 
Park and Halmann (US 6,526,163). 

Claims 10 and 23 were allowed. Claims 8 and 21 were objected to as being allowable if 
amended into independent form. 

Applicants respectfully request reconsideration of the rejections of claims 1-7, 1 1-20, 
22, and 24-29, including independent claims 1, 14, 28, and 29. 

Independent claim 1 recites a processor operable to interpolate where the interpolation 

is a function of three-dimensional rendering rays cast through the virtual volume, wherein the 
processor is configured to avoid scan-conversion from the polar coordinates of volume data 
that does not contribute to a final volume rendered image by scan converting only visible 
voxels based on the rendering rays and corresponding Cartesian coordinates, the identifying 
corresponding to identifying Cartesian coordinates associated with visible voxels of the final 
volume rendered image. Smith, et al. and Park do not disclose these limitations. 

Park is cited for use of a look-up-table in scan conversion (Office Action, pages 4 and 
5). Two-dimensional scan conversion is provided (col. 3, line 58; and see Figs. 1 and 2). 
Unit distance is used to scan convert for proceeding through the data (col. 4, lines 30-36). 
Park does not interpolate as a function of 3D rendering rays through a virtual volume. Park 
does not avoid scan-conversion for some data. Park does not identify associated with visible 
voxels in a volume rendered image. 

Smith, et al. form 3D data sets (col. 1, lines 59-64; and col. 3, lines 55-65). The 3D 
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data is used for generating slice images (col. 2, lines 10-18). The user selects slices in the 
volume (col. 11, lines 57-60; see Figs la-i). A scan converter produces an image selected by 
the user (col. 19, lines 40-44). X, y, z points are interpolated by stepping along the x, y and z 
dimensions in unit steps (col. 20, lines 62-66). These steps are along linear rays for 
horizontally producing raster lines for a slice plane (col. 20, line 62-col. 21, line 3). The 
raster scan moves down lines of a frame for generating any arbitrary slice in 3D space (col. 
21, lines 3-5). Smith, et al. scan converts one or more planes from a scanned volume using 
the plane position in 3D. Smith, et al. do not scan convert as a function of three-dimensional 
rendering rays cast through a virtual volume. The linear rays of Smith, et al. are display 
raster lines, not rays cast as part of volume rendering. 

Smith, et al. use data based on user positions of slices, so may avoid scan conversion 
of data not along the slices. However, Smith, et al. rely on slice position, not whether the 
voxel is visible based on rendering rays and not by identifying Cartesian coordinates 
associated with visible voxels of the final volume rendered image. 

Smith, et al. determine the locations of the slices based on user positioning in the 
volume. Smith, et al. do not use rays cast in a virtual volume free of voxel data. 

Even if Smith, et al. provide for volume rendering, there is not disclosure of the type 
of volume rendering used. Various types of volume rendering may be provided without 
using ray casting. 

Independent claim 14 is allowable for similar reasons as claim 1. 

Independent claim 28 recites a virtual Cartesian volume being free of voxel values. 
As noted above for claim 1, Smith, et al. do not use a virtual volume free of voxel values. 
Smith, et al. provide a scan volume of voxel values. 

Claim 28 recites volume rendering. Smith, et al. generate slice or sector images, not 
volume rendering. The use of viewport is not for a rendering, but instead for slices (col. 26, 
lines 39-41). 
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Claim 28 recites selectively determining, during the volume rendering, the spatial 
coordinates of the virtual Cartesian volume that are visible in order to avoid scan-conversion 
computations of acquired ultrasound data associated with polar coordinates for non- visible 
locations, only the acquired ultrasound data associated with the spatial coordinates of the 
virtual Cartesian volume that are visible contributing to a given view of the volume being 
scan converted, the determination of visibility being a fiinction of rays passing through the 
virtual Cartesian volume from an observer location. Smith, et al. do not consider visibility in 
the rendering context or as a function of rays passing through the volume from an observer 
location. 

Independent claim 29 is allowable for similar reasons as claim 28. 

Dependent claims 2-7, 9, 1 1-13, 15-20, 22, and 24-27 depend from claims 1 and 14, and 
are allowable for the same reasons as the corresponding base claim. Further limitations 
patentably distinguish from the cited references. 

Claims 5 and 18 recite volume rendering. Cited col. 4, lines 46-53 note selection of a 
sub- volume in 3D operation, but do not describe volume rendering. The imaging is slice 
imaging (see Fig. IC). Smith, et al. do not disclose rendering of the volume, just steering to 
a sub-volume for 3D scanning. The 3D echo data is used for imaging arbitrary slices. 

Claims 6 and 19 recite alpha blending. Averaging for interpolation (col. 20, lines 1- 
20) is not alpha blending. Interpolation is a different process than alpha blending. It is not 
inherent in interpolation to alpha blend. Claim 6 recites use of a threshold for blending. 
Smith, et al. use bilinear or cubic interpolation (2 or 4). This is not a threshold for blending. 
Alpha blending and blending in volume rendering are known terms. Interpolation for scan 
conversion is not alpha blending or thresholding. 

Claim 1 1 recites a GPU. Smith, et al. use a dedicated scan converter, not a GPU. 

Claim 12 recites a flag, and an integer sum. The Examiner alleges no criticality and 
mere design choice. As noted in the specification, an integer sum allows indication of spatial 
relationship relative to other table enfries. The claimed invention is about scan conversion, 
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which is a spatial relationship. The flag and integer sum efficiently track visibility for the 
claimed reverse lookup. Given the teachings of Smith, et al. and Park, a person of ordinary 
skill in the art would not have used the flag and integer sum as a design choice. 

Claim 27 recites volume rendering. The cited portion at col. 1, line 59-col. 2, line 18 
shows scanning a volume, but not rendering. For example, CW displays a spectrum and M- 
mode is a one-dimensional display in space with time as the other dimension. Smith, et al. 
provide for imaging arbitrary slices in the scanned volume, not volume rendering. 



Applicants respectfully submit that all of the pending claims are in condition for 
allowance and seeks early allowance thereof 

PLEASE MAIL CORRESPONDENCE TO: Respectfully submitted. 
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